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Abstract.  Dynamic  software  updating  (DSU)  systems  allow  running 
programs  to  be  patched  on-the-fly  to  add  features  or  fix  bugs.  While 
dynamic  updates  can  be  tricky  to  write,  techniques  for  establishing  their 
correctness  have  received  little  attention.  In  this  paper,  we  present  the 
first  methodology  for  automatically  verifying  the  correctness  of  dynamic 
updates.  Programmers  express  the  desired  properties  of  an  updated  exe¬ 
cution  using  client- oriented  specifications  (CO-specs),  which  can  describe 
a  wide  range  of  client-visible  behaviors.  We  verify  CO-specs  automati¬ 
cally  by  using  off-the-shelf  tools  to  analyze  a  merged  program,  which  is 
a  combination  of  the  old  and  new  versions  of  a  program.  We  formalize 
the  merging  transformation  and  prove  it  correct.  We  have  implemented  a 
program  merger  for  C,  and  applied  it  to  updates  for  the  Redis  key-value 
store  and  several  synthetic  programs.  Using  Thor,  a  verification  tool,  we 
could  verify  many  of  the  synthetic  programs;  using  Otter,  a  symbolic  ex¬ 
ecutor,  we  could  analyze  every  program,  often  in  less  than  a  minute.  Both 
tools  were  able  to  detect  faulty  patches  and  incurred  only  a  factor-of-four 
slowdown,  on  average,  compared  to  single  version  programs. 


1  Introduction 

Dynamic  software  updating  (DSU)  systems  allow  programs  to  be  patched  on- 
the-fly,  to  add  features  or  fix  bugs  without  incurring  downtime.  DSU  systems 
were  originally  developed  for  a  few  limited  domains  such  as  telecommunications 
networks,  financial  transaction  processors,  and  the  like,  but  are  now  becoming 
pervasive.  Ksplice,  recently  acquired  by  Oracle,  supports  applying  Linux  kernel 
security  patches  dynamically  [15].  The  Erlang  language,  which  provides  built- 
in  support  for  dynamic  updates,  is  gaining  in  popularity  for  building  server 
programs  [2].  Many  web  applications  employ  DSU  techniques  to  provide  24/7 
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service  to  a  global  audience — for  these  systems,  there  is  no  single  time  of  day 
when  taking  down  the  service  to  perform  upgrades  is  acceptable. 

Given  the  increasing  need  for  DSU,  a  natural  question  is:  How  can  developers 
ensure  a  dynamically  updated  program  will  behave  correctly?  Today,  developers 
need  to  reason  manually  about  all  the  pieces  of  an  updating  program:  the  old 
program  version,  the  new  program  version,  and  code  that  transforms  the  state  of 
the  (old)  running  version  into  the  form  expected  by  the  new  version.  Moreover, 
they  need  to  repeat  this  reasoning  process  for  each  allowable  “update  point” 
during  execution.  In  our  experience  this  is  a  tricky  proposition  in  which  it  is 
all  too  easy  to  make  mistakes.  Despite  such  difficulties,  most  DSU  systems  do 
not  address  the  issue  of  correctness,  or  they  focus  exclusively  on  generic  safety 
properties,  such  as  type  safety,  that  rule  out  obviously  wrong  behavior  [7,  22-24] 
but  are  insufficient  for  establishing  correctness  [11]. 

This  paper  presents  a  methodology  for  verifying  the  correctness  of  dynamic 
updates.  Rather  than  propose  a  new  verification  algorithm  that  accounts  for  the 
semantics  of  updating,  we  develop  a  novel  program  transformation  that  produces 
a  program  suitable  for  verification  with  off-the-shelf  tools.  Our  transformation 
merges  an  old  program  and  an  update  into  a  program  that  simulates  running 
the  program  and  applying  the  update  at  any  allowable  point.  We  formalize  our 
transformation  and  prove  that  it  is  correct  (Section  3). 

We  are  particularly  interested  in  using  our  transformation  to  prove  execution 
properties  from  clients’  points  of  view,  to  show  that  a  dynamic  update  does  not 
disrupt  active  sessions.  For  example,  suppose  we  wish  to  update  a  key- value  store 
such  as  Redis  [20]  so  that  it  uses  a  different  internal  data  structure.  To  verify 
this  update’s  transformation  code,  we  could  prove  that  values  inserted  into  the 
store  by  the  client  are  still  present  after  it  is  dynamically  updated.  We  call  such 
specifications  client- oriented  specifications  (or  CO-specs  for  short). 

We  have  identified  three  categories  of  CO-specs  that  capture  most  properties 
of  interest:  backward-compatible  CO-specs  describe  properties  that  are  identical 
in  the  old  and  new  versions;  post-update  CO-specs  describe  properties  that  hold 
after  new  features  are  added  or  bugs  are  fixed  by  an  update;  and  conformable 
CO-specs  describe  properties  that  are  identical  in  the  old  and  new  versions, 
modulo  uniform  changes  to  the  external  interface.  CO-specs  in  these  categories 
can  often  be  mechanically  constructed  from  CO-specs  written  for  either  the  old 
or  new  program  alone.  Thus,  if  a  programmer  is  inclined  to  verify  each  program 
version  using  CO-specs,  there  is  little  additional  work  to  verify  a  dynamic  up¬ 
date  between  the  two.  Nevertheless,  some  interesting  and  subtle  properties  lie 
outside  these  categories,  so  our  framework  also  allows  arbitrary  properties  to  be 
expressed  (Section  2). 

We  have  implemented  our  merging  transformation  for  C  programs  and  used  it 
in  combination  with  two  existing  tools  to  verify  properties  of  several  dynamic  up¬ 
dates  (Section  4).  We  chose  the  symbolic  executor  Otter  [21]  and  the  verification 
tool  Thor  [16]  as  they  represent  two  ends  of  the  design  space:  symbolic  execu¬ 
tion  is  easy  to  use  and  scales  reasonably  well  but  is  incomplete,  while  verification 
scales  less  well  but  provides  greater  assurance.  We  wrote  two  synthetic  bench- 
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marks,  a  key-value  store  and  a  multiset  implementation,  and  designed  dynamic 
patches  for  them  based  on  realistic  changes  (e.g.,  one  change  was  inspired  by  an 
update  to  the  storage  server  Cassandra  [5]).  We  also  wrote  dynamic  patches  for 
six  releases  of  Redis  [20],  a  popular,  open-source  key- value  store.  We  used  the 
Redis  code  as  is,  and  wrote  the  state  transformation  code  ourselves. 

We  checked  all  the  benchmark  programs  with  Otter  and  verified  several  prop¬ 
erties  of  the  synthetic  updates  using  Thor.  Both  tools  successfully  uncovered  bugs 
that  were  intentionally  and  unintentionally  introduced  in  the  state  transforma¬ 
tion  code.  The  running  time  for  verification  of  merged  programs  was  roughly 
four  times  slower  than  single-version  checking.  This  slowdown  was  due  to  the 
additional  branching  introduced  by  update  points  and  the  need  to  analyze  the 
state  transformer  code.  As  tools  become  faster  and  more  effective,  our  approach 
will  scale  with  them.  In  summary,  this  paper  makes  three  main  contributions: 

—  It  presents  the  first  automated  technique  for  verifying  the  behavioral  correct¬ 
ness  of  dynamic  updates. 

—  It  proposes  client- oriented  specifications  as  a  means  to  specify  general  update 
correctness  properties. 

—  It  shows  the  effectiveness  of  merging-based  verification  on  practical  examples, 
including  Redis  [20],  a  widely  deployed  server  program. 

2  Defining  dynamic  software  update  correctness 

Before  we  can  set  out  verifying  DSU  correctness,  we  have  to  decide  what  cor¬ 
rectness  is.  In  this  section,  we  first  review  previously  proposed  notions  of  cor¬ 
rectness  and  argue  why  they  are  insufficient  for  our  purposes.  Then  we  propose 
client- oriented  specifications  (CO-specs)  as  a  means  of  specifying  correctness 
properties,  and  argue  that  this  notion  overcomes  limitations  of  prior  notions. 
We  also  describe  a  simple  refactoring  that  allows  CO-specs  to  be  used  to  verify 
client-server  programs  that  communicate  over  a  network. 


2.1  Prior  work  on  update  correctness 

Kramer  and  Magee  [14]  proposed  that  updates  are  correct  if  they  are  observation- 
ally  equivalent-  i.e. ,  if  the  updated  program  preserves  all  observable  behaviors 
of  the  old  program.  Bloom  and  Day  [3]  observed  that,  while  intuitive,  this  is  too 
restrictive:  an  update  may  fix  bugs  or  add  new  features. 

To  address  the  limitations  of  strict  observational  equivalence,  Gupta  et  al.  [9] 
proposed  reachability.  This  condition  classifies  an  update  as  correct  if,  after  the 
update  is  applied,  the  program  eventually  reaches  some  state  of  the  new  program. 
Reachability  thus  admits  bugfixes,  where  the  new  state  consists  of  the  corrected 
code  and  data,  as  well  as  feature  additions,  where  the  new  state  is  the  old 
data  plus  the  new  code  and  any  new  data.  Unfortunately,  reachability  is  both 
too  permissive  and  too  restrictive,  as  shown  by  the  following  example.  Version 
1.1.2  of  the  vsftpd  FTP  server  introduced  a  feature  that  limits  the  number  of 
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connections  from  a  single  host.  If  we  update  a  running  vsftpd  server,  we  would 
expect  it  to  preserve  any  active  connections.  But  doing  so  violates  reachability. 
If  the  number  of  connections  from  a  particular  host  exceeds  the  limit  and  these 
connections  remain  open  indefinitely,  the  server  will  never  enter  a  reachable  state 
of  the  new  program.  On  the  other  hand,  reachability  would  allow  an  update  that 
terminates  all  existing  connections.  This  is  almost  certainly  not  what  we  want — if 
we  were  willing  to  drop  existing  connections  we  could  just  restart  the  server! 

We  believe  that  the  flaw  in  all  of  these  approaches  is  that  they  attempt  to 
define  correctness  in  a  completely  general  way.  We  think  it  makes  more  sense 
for  programmers  to  specify  the  behavior  they  expect  as  a  collection  of  proper¬ 
ties.  Some  properties  will  apply  to  multiple  versions  of  the  program  while  other 
properties  will  change  as  the  program  evolves.  Because  the  goal  of  a  dynamic 
update  is  to  preserve  active  processing  and  state,  the  properties  should  express 
the  expected  continuity  that  a  dynamic  update  is  meant  to  provide  to  active 
clients.  We  therefore  introduce  client- oriented  specifications  (CO-specs)  to  spec¬ 
ify  update  properties  that  satisfy  these  requirements. 


2.2  Client-oriented  specifications 

We  can  think  of  a  CO-spec  as  a  kind  of  client  program  that  opens  connections, 
sends  messages,  and  asserts  that  the  output  received  is  correct.  CO-specs  resem¬ 
ble  tests,  but  certain  elements  of  the  test  code  are  left  abstract  for  generality  (cf. 
Figure  1).  For  example,  consider  again  reasoning  about  updates  to  a  key-value 
store  such  as  Redis.  A  CO-spec  might  model  a  client  that  inserts  a  key- value  pair 
into  the  store  and  then  looks  up  the  key,  checking  that  it  maps  to  the  correct 
value  (even  if  a  dynamic  update  has  occurred  in  the  meantime).  We  can  make 
such  a  CO-spec  general  by  leaving  certain  elements  like  the  particular  keys  or 
values  used  unconstrained.  Similarly,  we  can  allow  arbitrary  actions  to  be  in¬ 
terleaved  between  the  insert  and  lookup.  Such  specifications  capture  essentially 
arbitrary  client  interactions  with  the  server. 

Our  goal  is  to  use  our  program  transformation,  defined  in  Section  3,  to  pro¬ 
duce  a  merged  program  that  we  can  verify  using  off-the-shelf  tools.  But  existing 
tools  only  verify  single  programs  in  isolation,  so  we  cannot  literally  write  CO- 
specs  as  client  programs  that  communicate  with  a  server  being  updated.  To 
verify  a  CO-spec  in  a  real  client-server  program  we  replace  the  server’s  main 
function  the  CO-spec  and  call  the  relevant  server  functions  directly.  In  doing 
so,  we  are  checking  the  server’s  core  functionality,  but  not  its  main  loop  or  any 
networking  code.  For  example,  suppose  our  key-value  store  implements  func¬ 
tions  get  and  set  to  read  and  write  mappings  from  the  store,  and  the  server’s 
main  loop  would  normally  dispatch  to  these  functions.  CO-specs  would  call  the 
functions  directly  as  shown  in  Figure  1.  Here,  ?  denotes  a  non-deterministically 
chosen  (integer)  value,  and  assume  and  assert  have  their  standard  semantics.  If 
updates  are  permitted  while  executing  either  get  or  set,  verifying  Figure  1(b) 
will  establish  that  the  assertions  at  the  end  of  the  specification  hold  no  matter 
when  the  update  takes  place. 
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int  get(int  k,  int  *v); 

10 

void  back_compat_spec()  { 

19 

void  post_update_spec()  { 

void  set  (int  k,  int  v); 

11 

int  k  =  ?,  vJn  =  ?; 

20 

int  k  =  ?; 

12 

int  v_out,  found; 

21 

int  v_out,  found; 

void  arbitrary  ( int  kl)  { 

13 

set(k,  vJn  ); 

22 

while(?)  arbitrary  (?); 

int  k2  =  ?,  v  =  ?; 

14 

while(?)  arbitrary  (k); 

23 

assume(is_updated); 

if  (kl  ==  k2  ||  ?) 

15 

found  =  get(k,&v_out); 

24 

delete  (k); 

get(k2,&v); 

16 

assert  (found  && 

25 

found  =  get(k,&v_out); 

else  set  (k2,v); 

17 

v_out  ==  vJn); 

26 

assert  (Ifound); 

} 

18 

} 

27 

} 

(a)  interface,  helper  (b)  backward-compat.  spec  (c)  post-update  spec 


Fig.  1.  Sample  C  specifications  for  key- value  store. 


In  our  experience  writing  CO-specs  for  updates,  we  have  found  that  they 
often  fall  into  one  of  the  following  categories: 

—  Backward-compatible  CO-specs  describe  behaviors  that  are  unaffected  by  an 
update.  For  the  data  structure-changing  update  to  Rcdis  mentioned  earlier, 
the  CO-spec  in  Figure  1(b)  would  check  that  existing  mappings  are  preserved. 

—  Post-update  CO-specs  describe  behavior  specific  to  the  new  program  version. 
For  example,  suppose  we  added  a  delete  feature  to  the  key-value  store.  Then 
the  CO-spec  in  Figure  1(c)  verifies  that,  after  the  update,  the  feature  is  work¬ 
ing  properly.  The  CO-spec  employs  the  flag  is_updated,  which  is  true  after  an 
update  has  taken  place,  to  ensure  that  we  are  testing  the  new  or  changed  func¬ 
tionality  after  the  update.  We  discuss  the  semantics  of  this  flag  in  Section  3. 

—  Conformable  CO-specs  describe  updates  that  change  interfaces,  but  preserve 
core  functionality.  For  example,  suppose  we  added  namespaces  to  our  key- value 
store,  so  that  get  and  set  take  an  additional  namespace  argument.  The  state 
transformation  code  would  map  existing  entries  to  a  default  namespace.  A 
conformable  CO-spec  could  check  that  mappings  inserted  prior  to  the  update 
are  present  in  the  default  namespace  afterward;  in  essence,  the  CO-spec  would 
associate  old-version  calls  with  new-version  calls  at  the  default  namespace. 
(Further  details  are  given  in  Appendix  A. 3.) 

These  categories  encompass  prior  notions  of  correctness.  Backward  compatible 
specifications  capture  the  spirit  of  Kramer  and  Magee’s  condition,  but  apply 
to  individual,  not  all,  behaviors.  The  combination  of  backward-compatible  and 
post-update  specifications  capture  Bloom  and  Day’s  notions  of  “future-only  im¬ 
plementations”  and  “invisible  extensions” — parts  of  a  program  whose  semantics 
change  but  not  in  a  way  that  affects  existing  clients  [3].  The  combination  of 
backward-compatible  and  conformable  specifications  match  ideas  proposed  by 
Ajrnani  et  al.  [1],  who  studied  dynamic  updates  for  distributed  systems  and 
proposed  mechanisms  to  maintain  continuity  for  clients  of  a  particular  version. 

CO-specs  can  also  be  used  to  express  the  constraints  intended  by  Gupta’s 
reachability  while  side-stepping  the  problem  that  reachability  can  leave  behavior 
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under-constrained.  For  example,  for  the  vsftpd  update  mentioned  above,  the 
programmer  can  directly  write  a  CO-spec  that  expresses  what  should  happen  to 
existing  client  connections,  e.g.,  whether  all,  some,  or  none  should  be  preserved. 
This  does  not  fall  into  one  of  the  categories  above,  demonstrating  the  utility  of  a 
full  specification  language  over  “one  size  fits  all”  notions  of  update  correctness. 

Another  feature  of  CO-specs  in  these  categories  is  that  they  can  be  mechan¬ 
ically  constructed  from  CO-specs  that  are  written  for  a  single  version.  Thus,  if  a 
programmer  was  inclined  to  verify  the  correctness  of  each  version  of  his  program 
using  CO-specs,  the  additional  work  to  verify  a  dynamic  update  is  not  much 
greater.  For  details,  see  Appendix  A. 

3  Verification  via  program  merging 

We  verify  CO-specs  by  merging  an  existing  program  version  with  its  update,  so 
that  the  semantics  of  the  merged  program  is  equivalent  to  the  updating  program. 
This  section  formalizes  a  semantics  for  dynamic  updates  to  single-threaded  pro¬ 
grams,  then  defines  the  merging  transformation  and  proves  it  correct  with  respect 
to  the  semantics.  Many  server  programs  for  which  dynamic  updating  is  useful 
are  single-threaded  [12,18,11].  However,  an  important  next  step  for  this  work 
would  be  to  adapt  it  to  support  updates  to  multi-threaded  (and  distributed) 
programs. 

3.1  Syntax 

The  top  of  Figure  2  defines  the  syntax  of  a  simple  programming  language  sup¬ 
porting  dynamic  updates.  It  is  based  on  the  Proteus  dynamic  update  calcu¬ 
lus  [22],  and  closely  models  the  semantics  of  common  DSU  systems,  includ¬ 
ing  Ginseng  [18]  (which  is  the  foundation  of  our  implementation),  Ksplice  [15], 
Jvolve  [23],  K42  [13],  DLpop  [12],  Dynamic  ML  [24]  and  Bracha’s  DSU  system  [4]. 

A  program  p  is  a  mapping  from  function  names  g  to  functions  Xx.e.  A  func¬ 
tion  body  e  is  defined  by  a  mostly  standard  core  language  with  a  few  extensions 
for  updating.  Our  language  contains  a  construct  update,  which  indicates  a  posi¬ 
tion  where  a  dynamic  update  may  take  effect.  To  support  writing  specifications, 
the  language  includes  an  expression  ?,  which  represents  a  random  integer,  and 
expressions  assume  v,  assert  v,  and  running  p,  all  of  whose  semantics  are  discussed 
below.  Expressions  are  in  administrative  normal  (A-normal)  form  [8]  to  keep  the 
semantics  simple — e.g.,  instead  of  ei+e2,  we  write  let  x  =  e\  in  let  y  =  e 2  in  x+y. 
We  write  ei;  e2  as  shorthand  for  let  x  =  e\  in  e2,  where  x  is  fresh  for  e2- 

3.2  Semantics 

The  semantics,  given  in  the  latter  half  of  Figure  2,  is  written  as  a  series  of  small- 
step  rewriting  rules  between  configurations  of  the  form  (p;cr;e),  which  contain 
the  program  p ,  its  current  heap  a,  and  the  current  expression  e  being  evaluated. 
A  heap  is  a  partial  function  from  locations  l  to  values  v,  and  a  location  l  is  either 
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Prog,  p  ::=  p,(g,Xx. 

.e)|- 

Variables  x,  y,  z 

Exprs.  e  ::=  v  \  Vi  op  V2  |  vi(v2)  |  ?  |  !tr  |  ref  v  \ 

Globals 

f,g 

th  :=  v2 

|  if  v  ei  e2  |  update 

Operators  op 

let  x  =  ei  in  e2  |  assume  v  | 

Integers  i,j 

while  ei 

do  e2  assert  v  \ 

Addresses  a 

running  p  |  error 

Heaps 

< j  £  Locs  — L  Values 

Values  v  ::=  x  \  l  \  i  \ 

(vi,v2)  |  () 

Patch 

7T  ::=  (p,e) 

Locs.  1  ::=  a  \  g 

Labels 

re  ::=  7r  |  e 

(p;cr;m  opv2) 

(P\cr;v') 

v'  =  [op](wi,  v2) 

(p;  a;  ref  v) 

^  (p;  cr[a  i-t  v];  a) 

a  dom(cr) 

(p;  c;  !Z) 

(p;  o';  v) 

a(l)  =  v  and  l  £  dom(p) 

(p;a;a  :=  v) 

(p;  a[a  i-t  v];  v) 

a  £  dom(a) 

{p;a-,g  :=  v) 

(p;cr[p  !-»■  vj;v) 

g  £  dom(p) 

(p;  cr;  ?> 

(p;  cr,  i) 

for  some  i 

(p;  a;  let  x  =  v  \n  e) 

(p;  cr;  e[v/a:]) 

(p;o;f(v)) 

(p;  cr;  e[v/a:]) 

p(f)  =  We 

(p;  cr;  if  0  ei  e2) 

(p;o-;e2) 

(p;  cr;  if  v  ei  e2) 

(p;  cr;  ei) 

(p;  a;  while  ei  do  e2) 

(p;  a;  let  a;  =  ei  in 

x  &fv{e i,e2) 

if  x  (e2;  while  ei 

do  e2)  0) 

(p;  a;  update) 

(p;  cr;  0) 

(p;  cr;  update) 

(Prr ;  cr;  (e*;  1)) 

7T  =  (pw,ew) 

(p;  cr;  running  p) 

(p;  cr;  1) 

(p;  cr;  running  p') 

(p;  cr;  0) 

P'  T^P 

(p;  cr;  assume  v) 

(p;  cr;  v) 

v  0 

(p;  cr;  assert  v) 

(p;  cr;  v) 

(p;  cr;  assert  0) 

^  (p;  cr;  error) 

(p;  cr;  let  x  =  error  in  r 

:)  (p;  cr;  error) 

(p;cr;e i)  (p';a 

';ei) 

(p; 

cr;  let  a;  =  ei  in  e2)  (p;;  cr 

';  let  x  =  e[ 

in  e2) 

Fig.  2.  Syntax  and  semantics. 


a  (dynamically  allocated)  address  a  or  a  (static)  global  name  g.  Note  that  while 
the  language  does  not  include  closures,  global  names  g  are  values,  and  so  the 
language  does  support  C-style  function  pointers.1 

Most  of  the  operational  semantics  rules  are  straightforward.  We  write  e[x/ 
u]  for  the  capture-avoiding  substitution  of  x  with  v  in  e.  We  assume  that  the 
semantics  of  primitive  operations  op  is  defined  by  some  mathematical  function 
[op];  e.g.,  [+]  is  the  integer  addition  function.  Loops  are  rewritten  to  condition- 

1  Variables  names  x  are  values  so  that  we  can  use  a  simple  grammar  to  enforce  A- 
normal  form.  The  downside  is  that  syntactically  well-formed  programs  could  pass 
around  unbound  variables  and  store  them  in  the  heap.  The  ability  to  express  such 
programs  is  immaterial  to  our  modeling  of  DSU,  and  could  be  easily  ruled  out  with 
a  simple  static  type  system. 
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als,  where  in  both  cases  a  non-zero  guard  is  treated  as  true  and  zero  is  treated  as 
false.  Addresses  a  for  dynamically  allocated  memory  must  be  allocated  prior  to 
assigning  to  them,  whereas  a  global  variable  g  is  created  when  it  is  first  assigned 
to.  This  semantics  allows  state  transformation  functions,  described  below,  to 
define  new  global  variables  that  are  accessible  to  an  updated  program. 

The  update  command  identifies  a  position  in  the  program  at  which  a  dynamic 
update  may  take  place.  Semantically,  update  non-deterministically  transitions 
either  to  0,  indicating  that  an  update  did  not  occur,  or  to  1  (eventually),  indi¬ 
cating  that  a  dynamic  update  was  available  and  was  applied.2  In  the  case  where 
an  update  occurs,  the  transition  arrow  is  labeled  with  the  patch  7r;  all  other 
(unadorned)  transitions  implicitly  have  label  e.  A  patch  ir  is  a  pair  (p„,en)  con¬ 
sisting  of  the  new  program  code  (including  unmodified  functions)  p v  and  an 
expression  that  transforms  the  current  heap  as  necessary,  e.g.,  to  update  an 
existing  data  structure  or  add  a  new  one  for  compatibility  with  the  new  program 
Pn-  In  practice,  en  will  be  a  call  to  a  function  defined  in  p The  transformer 
expression  e„  is  placed  in  redex  position  and  is  evaluated  immediately;  to  avoid 
capture,  non-global  variables  may  not  appear  free  in  eff.  Notice  that  an  update 
that  changes  function  /  has  no  effect  on  running  instances  of  /  since  evaluation 
of  their  code  began  prior  to  the  update  taking  place. 

The  placement  of  the  update  command  has  a  strong  influence  on  the  se¬ 
mantics  of  updates.  Placing  update  pervasively  throughout  the  code  essentially 
models  asynchronous  updates.  Or,  as  prior  work  recommends  [14,1,18,11],  we 
could  insert  update  selectively,  e.g.,  at  the  end  of  each  request-handling  function 
or  within  the  request-handling  loop,  to  make  an  update  easier  to  reason  about 

The  constructs  running  p,  assume  v.  and  assert  v  allow  us  to  write  specifica¬ 
tions.  The  expression  running  p  returns  1  if  p  is  the  program  currently  running 
and  0  otherwise;  i.e. ,  we  encode  a  program  version  as  the  program  text  itself. 
(In  Figure  1(c)  the  expression  is_updated  is  equivalent  to  running  p  where  p  is  the 
new  program  version.)  The  expression  assert  v  returns  v  if  it  is  non-zero,  and 
error  otherwise,  which  by  the  rule  for  let  propagates  to  the  top  level.  Finally,  the 
expression  assume  v  returns  v  if  v  is  non-zero,  and  otherwise  is  stuck. 

3.3  Program  merging  transformation 

We  now  present  our  program  merging  transformation,  which  takes  an  old  pro¬ 
gram  configuration  (p,  a ,  e)  and  a  patch  7r  and  yields  a  single  merged  program, 
configuration,  written  (p,  a,  e)  \>  n.  We  present  the  transformation  formally  and 
then  prove  that  the  merged  program  is  equivalent  to  the  original  program  with 
the  patch  applied  dynamically.  While  we  focus  on  merging  a  program  with  a  sin¬ 
gle  update,  the  merging  strategy  can  be  readily  generalized  to  multiple  updates 
(we  sketch  the  generalization  in  Appendix  B). 

The  definition  of  (p,  a,  e)  >  tt  is  given  in  Figure  3(e).  It  makes  use  of  functions 
[•]'  and  {|  •  |}',  defined  in  Figure  3(a)-(d).  We  present  the  interesting  cases;  the 

2  In  practice,  update  would  be  implemented  by  having  the  run-time  system  check  for 
an  update  and  apply  it  if  one  is  available  [12]. 
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b',(s,Ay.e)r*4 

I PT\  (<?,Ay.[e]p’F, 

(gptr,  Ay. let  z  =  isupdQ  in  if  z  g'(y)  g{y)) 

{|p',(y,Ay.e)|}p  A 

{b'|}p,(5',Ay.{|e|}p) 

[•Jp,7r  =  (•,  (isupd,  Ay. let  z  =  \uflag  in  z  >  0)) 

(i  •  r  =  • 

(a)  Old  version  programs 

(b)  New  version  programs 

l9iP’n  = 

( gptr  if  p(g)  =  Xx.e 

1  g  otherwise 

[running  p"]p>(pw ,e"'>  — 

[let  z  =  isupd()  in  z  =  0  if  p  =  p" 

<  isupd  ()  if  Pn  =  p" 

y  0  otherwise 

[updatef’^’^  A 
let  z  =  isupd()  in 
if  z  0  ( uflag  :=  ?; 

let  z  =  isupd( )  in  if  z  ({|e|}p,r;  1)  0) 

M”  = 

f  g'  if  p(g)  =  A*.e 

1  g  otherwise 
{|running  p"|}p  = 
j  1  if  p  =  p" 

1 0  otherwise 

{|update|}p  =  0 

(c)  Old  version  expressions 

(d)  New  version  expressions 

(p;  cr;  e)  >  7r  A  (p;  cr[uflag  i-t  i\,e) 

where  (pn,  ew)  =  tt  p  =  [p]p,7r  e  =  [e]p>,r 

i  <  0  a  =  {l  i-t  [u]p,,r  |  cr(l)  =  v} 

(e)  Merging  a  configuration  and  a  patch 

Fig.  3.  Merging  transformation  (partial). 


remaining  cases  are  translated  structurally  in  the  natural  way.  For  simplicity,  the 
transformation  assumes  the  updated  program  p „  does  not  delete  any  functions 
in  p.  Deletion  of  function  /  can  be  modeled  by  a  new  version  of  /  with  the  same 
signature  as  the  original  and  the  body  assert(O). 

The  merging  transformation  renames  each  new- version  function  from  g  to  g' , 
and  changes  all  new-version  code  to  call  g'  instead  of  g  (the  first  rewrite  rules  in 
Figure  3(b)  and  (d),  respectively).  For  each  old-version  function  g ,  it  generates 
a  new  function  gptr  whose  body  conditionally  calls  the  old  or  new  version  of  g, 
depending  on  whether  an  update  has  occurred  (Figure  3(a)).  The  transformation 
introduces  a  global  variable  uflag  (Figure  3(e))  and  a  function  isupd  to  keep  track 
of  whether  the  update  has  taken  place  (bottom  of  Figure  3(a)).  All  calls  to  g  in 
the  old  version  are  rewritten  to  call  gptr  instead  (top  of  Figure  3(c)). 

The  transformation  rewrites  occurrences  of  update  in  old- version  code  into 
expressions  that  check  whether  uflag  is  positive  (bottom  of  Figure  3(c)).  If  it  is, 
then  the  update  has  already  taken  place,  so  there  is  nothing  to  do.  Otherwise, 
the  transformation  sets  uflag  to  ?,  which  simulates  a  non-deterministic  choice 
of  whether  to  apply  the  update.  If  uflag  now  has  a  positive  value,  the  update 
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path  was  chosen,  so  the  transformation  executes  the  developer-provided  state 
transformation  e,  which  must  also  be  transformed  according  to  {|  •  [}'  to  prop¬ 
erly  reference  functions  in  the  new  program.  While  this  transformation  results 
in  multiple  occurrences  of  the  expression  e,  in  practice  e  is  a  call  to  a  state 
transformation  function  defined  in  the  new  version  and  so  does  not  significantly 
increase  code  size. 

Version  tests  running  p  are  translated  into  calls  to  isupd  in  the  old  version, 
and  to  appropriate  constants  in  the  new  code  (since  we  know  the  update  has 
occurred  if  new  code  is  running). 


3.4  Equivalence 

We  can  now  prove  that  an  update  to  an  old-program  configuration  is  correct  if 
and  only  if  the  result  of  merging  that  configuration  and  the  update  is  correct. 
This  result  lets  us  use  stock  verification  tools  to  check  properties  of  dynamic 
updates  using  the  merged  program,  which  simulates  updating,  instead  of  having 
to  develop  new  tools  or  extend  existing  ones. 

We  say  that  a  program  and  a  sequence  of  updates  are  correct  if  evaluation 
never  reaches  error  (i.e. ,  if  there  are  no  assertion  failures).  More  formally: 

Definition  1  (Correctness)  A  configuration  (p;  a;  e)  and  an  update  7r  are  cor¬ 
rect,  written  |=  {p\c r;e),7r,  if  and  only  if  for  all  p',a',e'  it  is  the  case  that 
(p;  a;  e)  (p'\  o'  \  e')  implies  e!  is  not  error. 

The  expression  e  at  startup  could  be  a  call  to  an  entry-point  function  (i.e.,  main). 
A  correct  program  need  not  apply  7 r,  though  no  other  update  may  occur.  When 
no  update  is  permitted  we  write  \=  (p;  o;  e). 

Theorem  1  (Equivalence)  For  allp.a^,!:  such  that  dom(pn)  3  dom(p)  we 
have  that  \=  (p;cr;e),7r  if  and  only  if  |=  ((p,  cr,  e)  [>  7r). 

The  proof  is  by  bisinrulation  and  is  given  in  Appendix  C  along  with  proof  sketches 
of  key  supporting  lemmas. 

Observe  that  type  errors  result  in  stuck  programs,  e.g.,  !1  does  not  reduce, 
while  the  above  theorem  speaks  only  about  reductions  to  error.  We  have  chosen 
not  to  consider  type  safety  in  the  formal  system  to  keep  things  simple;  adding 
types,  we  could  appeal  to  standard  techniques  [22-24,7].  Our  implementation 
catches  type  errors  that  could  arise  due  to  a  dynamic  update  by  transforming 
them  into  assertion  violations.  In  particular,  we  rename  functions  and  global  vari¬ 
ables  whose  type  has  changed  prior  to  merging,  essentially  modeling  the  change 
as  a  deletion  of  one  variable  and  the  addition  of  another.  Deleted  functions  are 
modeled  as  mentioned  above,  and  deleted  global  variables  are  essentially  as¬ 
signed  the  error  expression.  Thus,  any  old  code  that  accesses  a  stale  definition 
post-update  (including  one  with  a  changed  type)  fails  with  an  assertion  violation. 
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4  Experiments 

To  evaluate  our  approach,  we  have  implemented  the  merging  transformation  for 
C  programs,  with  the  additional  work  to  handle  C  being  largely  routine.  We 
merged  several  programs  and  dynamic  updates  and  then  checked  the  merged 
programs  against  a  range  of  CO-specs.  We  analyzed  the  merged  programs  using 
two  different  tools:  the  symbolic  executor  Otter,  developed  by  Ma  et  al.  [21],  and 
the  verification  tool  Thor,  developed  by  Magill  et  al.  [17].  The  tools  represent  a 
tradeoff:  Otter  is  easier  to  use  and  more  scalable  but  provides  incomplete  assur¬ 
ance,  while  Thor  can  guarantee  correctness  but  is  less  scalable  and  requires  more 
manual  effort.  Overall,  both  tools  proved  useful.  Otter  successfully  checked  all 
the  COs-specs  we  tried,  generally  in  less  than  one  minute.  Thor  was  able  to  fully 
verify  several  updates,  though  running  times  were  longer.  Both  tools  found  bugs 
in  updates,  including  mistakes  we  introduced  inadvertently.  On  average,  verifi¬ 
cation  of  merged  code  took  four  times  longer  than  verification  of  a  single  version. 
Since  our  approach  is  independent  of  the  verification  tool  used,  its  performance 
and  effectiveness  will  improve  as  advances  are  made  in  verification  technology. 

4.1  Programs 

We  ran  Otter  and  Thor  on  updates  to  three  target  programs.  The  first  two 
are  small,  synthetic  examples:  a  multiset  server,  which  maintains  a  multiset  of 
integer  values,  and  a  key-value  store.  For  each  program,  we  also  developed  a 
number  of  updates  inspired  by  common  program  changes  such  as  memory  and 
performance  optimizations  and  semantic  changes  observed  in  real-world  systems 
such  as  Cassandra  [5].  The  third  program  we  considered  is  Redis  [20],  a  widely 
used  open-source  key-value  server.  At  roughly  12k  lines  of  C  code,  Redis  is 
significantly  larger  that  our  synthetic  examples,  and  is  currently  not  tractable 
for  Thor.  We  developed  six  dynamic  patches  for  Redis  that  update  between  each 
pair  of  consecutive  versions  from  1.3.6  through  1.3.12,  and  we  also  wrote  a  set 
of  CO-specs  that  describe  basic  correctness  properties  of  the  updates. 

As  we  mention  in  Section  2,  we  join  each  CO-spec  with  the  server  code 
and  have  the  main  function  invoke  the  CO-spec  after  it  initializes  server  data 
structures.  The  new-version  source  code  includes  the  state  transformation  code, 
which  is  identified  by  a  distinguished  function  name  recognized  by  the  merger. 

Synthetic  Examples.  Figure  4  lists  the  synthetic  benchmarks  we  constructed  for 
our  multiset  and  key-value  store  programs.  Each  grouping  of  rows  shows  a  dy¬ 
namic  update  and  a  list  of  CO-specs  we  wrote  for  that  update.  The  multiset 
program  has  routines  to  add  and  delete  elements  and  to  test  membership.  The 
updates  both  change  to  a  set  semantics,  where  duplicate  elements  are  disal¬ 
lowed.  The  first  (correct)  state  transformer  removes  all  duplicates  from  a  linked 
list  that  maintains  the  current  multiset.  The  second  update  has  a  broken  state 
transformer  that  fails  to  remove  duplicates. 

The  key- value  store  program  also  implements  its  store  with  a  linked  list.  The 
updates  are  inspired  by  code  changes  we  have  seen  in  practice  and  include  a  bug 
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Program  -  change 

Thor  time  (s) 

Otter  time  (s) 

CO-specs 

old 

new 

mrg 

old 

new 

mrg 

Multiset  -  disallow  duplicates  (correct) 
mem-mem” 

90.11 

121.27 

1003.22 

6.29 

9.72 

49.37 

add-mem6 

64.17 

89.71 

537.01 

3.26 

10.48 

50.84 

add-add-del-set9 

- 

4.04 

Multiset  -  disallow  duplicates  (broken) 
mem-mem6 

25.33 

57.78 

133.68 

6.28 

9.77 

42.5 

add-mem6 

15.68 

33.50 

80.07 

3.25 

9.94 

33.53 

add-add-del-set-fails9 

122.71 

5.49 

Key- value  store  -  bug  fix 
put-get6 

27.01 

26.13 

41.62 

3.28 

2.54 

18.42 

new-def-shadows9 

- 

4.19 

new-def-shadows-bc- fails6 

38.97 

41.52 

117.56 

3.88 

2.06 

19.03 

Key-value  store  -  added  namespaces 
new-def-shadows-postp 

1.02 

2.99 

put-get9 

- 

- 

18.32 

228.69 

new-def-shadows-conF 

- 

- 

- 

1.19 

1.93 

7.53 

put-get-conF 

- 

- 

- 

4.23 

7.09 

61.41 

Key-value  store  -  optimization  (broken) 
put-get-back6 

42.133 

2.08 

11.01 

56.44 

new-def-shadows-back6 

15.344 

- 

- 

2.14 

11.33 

56.03 

Key-value  store  -  optimization  (correct) 
put-get-back6 

41.87 

_ 

2.07 

10.87 

69.31 

new-def-shadows-back6 

15.72 

- 

- 

2.14 

10.96 

68.95 

b  -  backward  compatible  p  -  post  update  c  -  conformable  g  -  general 
A  dash  indicates  that  the  example  could  not  be  verified. 


Fig.  4.  Synthetic  examples. 


fix  (bindings  could  not  be  overwritten),  a  feature  addition  (adding  namespaces), 
and  an  optimization  (removing  overwritten  bindings),  where  for  this  last  update 
the  state  transformer  was  broken  at  first. 

The  properties  span  all  the  categories  of  CO-specs  that  we  outlined  in  Sec¬ 
tion  2.  Backward  compatible  specs,  such  as  add-mem,  check  core  functionality 
that  does  not  change  between  versions  (add  actually  adds  elements,  delete  re¬ 
moves  elements,  etc.).  Post-update  and  general  CO-specs  are  used  to  check  that 
functionality  does  change,  but  only  in  expected  ways.  For  example,  new-def- 
slradows  in  the  bug-fix  update  checks  that,  following  the  update,  new  key-value 
bindings  properly  overwrite  old  bindings  (which  was  not  true  in  the  old  version). 

We  wrote  specifications  to  be  as  general  as  possible.  For  example,  add-nrem, 
on  the  second  line  of  the  table  in  Figure  4,  checks  that  after  an  element  is  added, 
it  is  reported  as  present  after  an  arbitrary  sequence  of  function  calls  that  does 
not  include  deleteQ.  The  code  for  our  synthetic  examples  and  their  associated 
CO-specs  is  available  on-line.3 

3  http:/ /www.cs.umd.edu/projects/PL/dsu/data/dsumerge-examples.tar.gz 
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Redis.  Figure  5  lists  the  updates  and  CO-specs  for  Redis.  Four  of  the  six  updates 
required  writing  state  transformers,  often  just  to  initialize  added  fields  but  some¬ 
times  to  perform  more  complex  transformation,  e.g.,  the  update  to  1.3.9  required 
some  reorganization  of  data  structures  storing  the  main  database. 

We  found  that  across  these  updates,  there  were  four  different  kinds  of  behav¬ 
ioral  changes,  each  of  which  suggested  a  certain  strategy  for  developing  CO-specs; 
we  employed  CO-specs  in  each  of  the  classes  described  in  Section  2: 

—  Unmodified  behavior:  We  adapted  two  CO-specs  from  our  synthetic  key-value 
store  example  (Figure  4),  put-get  and  new- def- shadows,  to  check  correct  be¬ 
havior  of  Redis’  SET  and  GET  operations  over  string  values.  As  these  CO-specs 
concern  behavior  that  all  versions  of  Redis  should  exhibit,  we  applied  them  as 
backward  compatible  CO-specs. 

—  New  operations:  The  HASHINCRBY  operation,  which  adds  to  the  numeric 
value  stored  for  a  hash  key,  first  appeared  in  version  1.3.8.  We  check  the 
operation’s  correctness  using  a  post- update  CO-spec,  hashincrby.  The  HASH¬ 
INCRBY  operation  is  supported  by  all  later  versions,  and  so  we  also  developed 
a  backward  compatible  hashincrby  CO-spec  for  subsequent  updates. 

—  Modified  semantics:  Before  Redis  version  1.3.8,  a  set  whose  last  element  was 
removed  would  remain  in  the  database.  We  use  the  backward  compatible  CO- 
spec  empty -set- exists  to  check  this  property  against  the  patch  to  1.3.7.  Then 
for  the  patch  to  1.3.8,  which  causes  the  server  to  remove  a  set  when  it  becomes 
empty,  we  use  a  general  CO-spec  empty-set-notexists  to  ensure  that  sets  are 
removed  if  they  become  empty  after  the  update.  Subsequent  versions  preserve 
this  behavior,  which  we  specify  using  a  backward  compatible  CO-spec. 

—  Conformable  changes:  Redis’s  ZINTER  operation,  which  computes  the  inter¬ 
section  of  two  sorted  sets,  was  renamed  to  ZINTERSTORE  in  version  1.3.12. 
We  use  a  conformable  CO-spec,  zinter,  to  specify  correct  behavior  regardless 
of  when  an  update  occurs. 

To  make  symbolic  execution  tractable  for  Redis,  we  had  to  bound  the  non¬ 
determinism  in  our  CO-specs,  e.g.,  by  limiting  “arbitrary  behavior”  to  a  single 
operation,  non-deterministically  chosen  from  a  subset  of  commands  that  relate 
to  the  specified  property  (rather  than  from  the  full  set  of  Redis  operations). 


4.2  Effectiveness 

In  most  cases,  checking  CO-specs  validated  the  correctness  of  our  dynamic 
patches.  In  some  cases  the  checking  found  bugs.  For  example,  in  the  state  trans¬ 
former  for  the  multiset-to-set  update,  we  inadvertently  introduced  a  possible  null 
pointer  dereference  when  freeing  duplicates.  Verification  with  Thor  discovered 
this  problem.  For  Redis,  we  experimented  with  omitting  state  transformation 
code  or  using  code  with  a  simple  mistake  in  it.  In  all  cases,  checking  our  speci¬ 
fications  with  Otter  uncovered  the  mistakes. 

Figures  4  and  5  show  the  running  times  for  each  of  the  update/CO-spec/tool 
combinations,  listed  under  the  mrg  heading.  As  a  baseline,  we  also  list  the 
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Fig.  5.  Otter  checking  times  for  Redis 


running  times  for  the  backward-compatible  specifications  on  both  individual 
program  versions,  and  for  post-update  specifications  on  the  new  version-  —this 
lets  us  compare  the  relative  slowdown  incurred  by  reasoning  about  updates. 

Otter.  We  performed  experiments  with  Otter  on  a  machine  with  a  dual-core 
Pentiunr-D  3.6GHz  processor  and  2GB  of  memory.  The  running  times  range 
from  seconds  to  a  few  minutes,  depending  on  the  complexity  of  the  specification 
and  the  program.  For  example,  the  CO-specs  for  the  multiset-to-set  example 
were  expensive  to  symbolically  execute  because  each  set  insertion  checks  for 
duplicates,  which  induces  many  branches  when  symbolic  values  are  involved. 

We  also  see  that,  across  the  synthetic  examples  and  Redis,  it  takes  four  times 
longer  to  analyze  merged  programs  versus  individual  versions  on  average,  and 
6.4  times  longer  in  the  worst  case.  We  investigated  the  source  of  the  slowdown, 
and  found  it  was  due  to  the  extra  time  required  to  model  update  points  and 
state  transformers,  which  is  fundamental  to  verifying  updating  programs,  rather 
than  an  artifact  of  our  merging  strategy.  In  particular,  Otter  runs  on  the  merged 
versions,  so  it  must  explore  additional  program  paths  to  model  each  possible  up¬ 
date  timing;  on  average,  CO-specs  reached  3.7  update  points  during  execution 
and,  loosely  speaking,  each  update  point  could  induce  another  full  exploration 
through  the  set  of  non-updating  program  paths.  State  transformation  is  also  exe¬ 
cuted  following  updates,  so  the  expense  of  symbolically  executing  the  transformer 
is  multiplied  by  the  number  of  times  an  update  point  is  reached.  Nevertheless, 
despite  this  slowdown,  total  checking  time  was  rarely  an  impediment  to  checking 
useful  properties. 

Thor.  We  ran  Thor  on  a  2.8GHz  Intel  Core  2  Duo  with  4GB  of  memory.  The 
average  slowdown  was  3.9  times,  and  ranged  from  1.5  times  to  8.3  times.  Much  of 
the  slowdown  derived  from  per-update-point  analysis  of  the  state  transformation 
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function;  tools  that  compute  procedure  summaries  or  otherwise  support  modular 
verification  would  likely  do  better.  Thor  could  not  verify  all  our  examples,  owing 
to  complex  state  transformation  code  and  CO-specs  that  specify  very  precise 
properties.  For  example,  for  the  multiset-to-set  example,  Thor  was  able  to  prove 
that  the  state  transformer  preserves  list  membership  (used  to  verify  mem-mem ), 
but  not  that  it  leaves  at  most  one  copy  of  any  element  in  the  list  (needed  for 
add-add-del-set) . 

The  CO-specs  we  considered  lie  at  the  boundary  of  what  is  possible  for  cur¬ 
rent  verification  technology.  To  verify  all  our  examples  requires  a  robust  treat¬ 
ment  of  pointer  manipulation,  integer  arithmetic,  and  reasoning  about  collec¬ 
tions.  We  are  not  aware  of  any  tools  that  currently  offer  such  a  combination. 
However,  we  hope  that  the  demonstrated  utility  of  such  specifications  will  help 
inspire  further  research  in  this  area. 

5  Related  work 

This  paper  presents  the  first  approach  for  automatically  verifying  the  correctness 
of  dynamic  software  updates.  As  mentioned  in  the  introduction,  prior  automated 
analyses  focus  on  safety  properties  like  type  safety  [22],  rather  than  correctness. 
As  described  in  Section  2,  our  notion  of  client-oriented  specifications  captures 
and  extends  prior  notions  of  update  correctness. 

Our  verification  methodology  generalizes  our  prior  work  [10, 11]  on  system¬ 
atically  testing  dynamic  software  updates.  Given  tests  that  pass  for  both  the 
old  and  new  versions,  the  tool  tests  every  possible  updating  execution.  This  ap¬ 
proach  only  supported  backward-compatible  properties  and  does  not  extend  to 
general  properties  (e.g.,  with  non-deterministically  chosen  operations  or  values). 

The  merging  transformation  proposed  in  this  paper  was  inspired  by  KISS  [19], 
a  tool  that  transforms  multi-threaded  programs  into  single-threaded  programs 
that  fix  the  timing  of  context  switches.  This  allows  them  to  be  analyzed  by  non¬ 
thread-aware  tools,  just  as  our  merging  transformation  makes  dynamic  patches 
palatable  to  analysis  tools  that  are  not  DSU-aware. 

An  alternative  technique  for  verifying  dynamic  updates,  explored  by  Charlton 
et  al.  [6],  uses  a  Hoare  logic  to  prove  that  programs  and  updates  satisfy  their 
specifications,  expressed  as  pre/post-conditions.  We  find  CO-specs  preferable  to 
pre/post-conditions  because  they  require  less  manual  effort  to  verify,  and  because 
they  naturally  express  rich  properties  that  span  multiple  server  commands. 

6  Summary 

We  have  presented  the  first  system  for  automatically  verifying  dynamic-software- 
update  (DSU)  correctness.  We  introduced  client- oriented  specifications  as  a  way 
to  specify  update  correctness  and  identified  three  common,  easy-to-construct 
classes  of  DSU  CO-specs.  To  permit  verification  using  non-DSU-aware  tools,  we 
developed  a  technique  where  the  old  and  new  versions  are  merged  into  a  single 
program  and  proved  that  it  correctly  models  dynamic  updates.  We  implemented 
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merging  for  C  and  found  that  it  enabled  the  analysis  tool,  Thor,  to  fully  verify 
several  CO-specs  for  small  updates,  and  the  symbolic  executor,  Otter,  to  check 
and  find  errors  in  dynamic  patches  to  Redis,  a  widely-used  server  program. 
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A  Client-oriented  update  specifications 

In  Section  2  We  introduced  three  categories  of  CO-spec  for  verifying  dynamic 
updates:  backward  compatible  specifications,  post-update  specifications,  and  con¬ 
formable  specifications.  In  this  section  we  discuss  the  specification  categories 
in  more  detail  and  show  how  they  can  be  constructed  mechanically  given  CO- 
specs  that  apply  to  either  the  old  or  new  program  version.  As  such,  we  believe 
that  verifying  a  dynamic  patch  should  add  little  work  beyond  the  work  already 
needed  to  verify  the  old  and  new  program  versions  in  isolation. 

A.l  Backward  compatible  CO-specs 

Most  programs  satisfy  many  of  the  same  properties  before  and  after  a  dynamic 
update — e.g.,  most  of  a  server’s  behavior  that  the  client  observes  is  often  un¬ 
changed  between  versions.  For  instance,  Hayden  et  al.  observed  that  OpenSSH’s 
test  suite  only  grew  between  versions — all  of  the  old  tests  continued  to  hold  as 
time  went  on  [11].  This  makes  intuitive  sense:  many  updates  simply  add  new 
features,  leaving  the  old  features  (and  properties  about  them)  unchanged,  or 
refactor  the  program  to  improve  non-functional  aspects  such  as  performance. 

A  backward-compatible  CO-spec  4>  is  one  that  holds  for  both  the  old  and  new 
versions  independently.  Such  CO-specs  are  immediately  usable.  For  example, 
the  CO-spec  in  Figure  1(b)  might  apply  to  the  old  and  new  program  version, 
and  thus  it  immediately  applies  to  an  updating  execution;  assuming  the  update 
could  take  place  during  calls  to  get  or  set,  we  would  verify  that  the  update  does 
not  drop  mappings  from  the  store. 

A. 2  Post-update  CO-specs 

Another  common  category  of  properties  consists  of  those  that  apply  to  the  new 
version  but  not  the  old  version.  An  example  was  given  in  Figure  1(c):  after 
dropping  line  assume  on  line  23,  we  could  apply  this  CO-spec  directly  to  the  new 
version,  to  verify  the  behavior  of  a  newly  added  delete  command.  By  adding  this 
line,  we  are  able  to  verify  executions  in  which  arbitrary  operations  are  performed 
by  the  old  version,  but  delete  is  not  tested  until  after  the  update  takes  place. 

Given  a  new-version  CO-spec  (f>,  we  can  mechanically  transform  it  into  a  post¬ 
update  CO-spec  4>\  as  follows.  We  can  prefix  <f>  with  an  arbitrary  sequence  of  calls 
into  the  old  program  version,  ending  with  the  assumption  assume  (running  pi) 
to  ensure  the  new  version  pi  is  running  when  <f>  is  checked.  Figure  6(a)  formally 
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V\4>\  =  while  ?  do 

assume  (running  po); 

if  ?  then  /0(?)  else  if  ?  then  /i(?)  else  .  . . 
assume  (running  pi); 

_ <fi _ 

(a)  Post-update  function  V\-\ 

C[/(t>) ]  =  if  (running  p0)  then  ^[/(v)]  else  f(v) 

defined 

C{f(v) ]  =  assume  (running  pi);f(v) 

tfF\f(v)\  undefined 
Cflet  x  =  e  in  e']  =  let  x  =  C[e]  in  C\e'\ 

CJwhile  e  do  e']  =  while  C\e\  do  C\e'\ 

C\4>'\  =  4>'  for  all  other  <j> 

(b)  Conformance  function  C[-] 


<t 

cm 

let  k  =  ?  in 

let  k  =?  in 

let  x  =  ?  in 

let  x  =?  in 

set(d,  k,  x); 

if  (running  po)  then  set(k,v) 

else  set(d,  k,  v ); 

del(d,  fc); 

assume  (running  pi);  del(d,  fc); 

let  x"  =  get(d,  k)  in 

let  x"  =  (if  (running  po)  then  get(k) 

else  get(d,  k))  in 

assert  (x"  =  error ) 

assert  (x"  =  error) 

(c)  Conforming  new- version  spec  <j>  using  C [•]  defined  in  (b) 


Fig.  6.  Transforming  new- version  specifications 
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defines  this  transformation  as  the  post-update  CO-spec  where  po  defines 

the  functions  /0,  /i, . . ..  Thus,  V\(j)\  can  now  be  checked  against  an  update  from 
p0  to  pi . 

Post-update  CO-specs  often  make  sense  for  updates  that  add  features  or  fix 
bugs.  However,  in  general  only  CO-specs  that  assume  the  server  could  be  in 
an  arbitrary  initial  state  are  suitable  for  the  post-update  transformation.  As  a 
trivial  example,  the  CO-spec  assert  ( get( ?)  =  error)  explicitly  checks  that  our 
key-value  store  starts  empty,  and  may  not  hold  immediately  after  an  update. 

A. 3  Conformable  CO-specs 

In  some  cases,  updates  change  the  behavior  of  existing  features  in  a  systematic 
way.  For  example,  the  Cassandra  distributed  database  [5]  added  namespaces  to 
its  key-value  store  when  moving  from  version  0.3  and  0.4.  Thus,  the  new  set  of 
server  functions  now  take  a  namespace  identifier  as  an  initial  parameter,  i.e. , 
set(d,k,v)  associates  key  k  to  value  v  in  namespace  d,  and  likewise  get(d,k)  re¬ 
trieves  the  value  associated  with  k  in  namespace  d.  After  making  this  change, 
the  developer  adapts  the  existing  single- version  specifications  for  the  old  version 
to  be  compatible  with  the  new  version.  For  example,  the  specification  in  Fig¬ 
ure  1(b)  would  be  adjusted  so  that  calls  to  get  and  set  are  made  using  some 
default  namespace  identifier. 

To  perform  this  update  dynamically,  the  developer  must  write  a  patch  7r 
whose  state  transformation  expression  e  adjusts  the  key-value  store  to  be  com¬ 
patible  with  the  new  code — e.g.,  any  existing  key- value  pairs  already  in  the 
server  heap  could  be  placed  in  a  default  namespace.  A  reasonable  choice  is  to 
have  e  add  a  default  namespace  d  to  each  existing  key-value  pair.  To  test  that 
this  update  provides  reasonable  continuity,  we  can  take  a  new-version  specifica¬ 
tion  (f)  that  uses  this  default  namespace  and  adapt  it  so  that  it  starts  by  using 
the  old  versions  of  the  changed  functions,  and  then  changes  to  the  new  version 
midstream. 

We  can  mechanize  this  process  as  follows.  We  assume  we  are  given  a  new  spec¬ 
ification  <p ,  as  well  as  a  meta-function  ^[/(u)]  that  takes  a  call  to  a  new-version 
function  and  transforms  it  to  an  appropriate  call  to  an  old- version  function.  As 
this  may  not  always  be  possible,  -F[-]  may  be  partial.  Then  we  can  define  the 
meta-function  C\(jj\  that  conforms  <f>  as  shown  in  Figure  6(b).  For  our  example, 
the  developer  would  define  F\get(d,k)\  =  getfk )  and  lF\set(d,  k,  t>)]  =  set(k,v). 
Note  that  -F[-]  bears  some  resemblance  to  Ajmani  et  al.’s  future  simulation  ob¬ 
jects  [1],  which  are  bits  of  code  added  to  old- version  servers  whose  aim  is  to 
convert  calls  from  new  clients  to  work  with  the  old  code.  We  are  not  deploying 
these  conformance  functions  on-line,  but  rather  are  using  them  to  adjust  existing 
specifications  to  check  proper  continuity  following  an  update. 

Now  suppose  that  the  new  version  also  adds  a  new  function  that  permits  a 
client  to  delete  an  entry:  del(d,k)  removes  any  association  with  k  from  names¬ 
pace  d.  Since  there  is  no  analogue  to  del  defined  in  the  old  version,  there  is  no 
backward  translation  for  calls  del(d,k)  that  could  appear  in  new-version  spec¬ 
ifications.  To  see  how  C[-J  works  in  this  case,  consider  the  example  given  in 
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Figure  6(c),  which  shows  <j>  and  C\(j)\  side  by  side.  Here,  C[0]  permits  updates 
to  happen  up  until  the  del  call,  at  which  point  we  assume  the  update  has  taken 
place.  (This  means  that  the  running  p0  check  that  follows  it  will  always  be  false.) 

B  Handling  multiple  updates 

The  merging  transformation  in  Figure  3  merges  a  program  with  a  single  up¬ 
date.  This  transformation  can  be  generalized  to  prove  properties  about  multi¬ 
ple  updates.  To  see  the  basic  idea,  consider  a  process  (p,  a,  e )  and  a  sequence 
of  two  updates  7Ti  and  7t2  .  We  would  first  merge  (p,  a,  e)  and  7Ti ,  producing 
(p,  o\  e)  >  7r i .  Then  we  would  merge  the  result  with  7T2,  essentially  producing 
(( p,a,e )  I>  7T! )  >  7t2.  To  do  this  properly  requires  some  small  changes  to  the 
transformation.  First,  we  need  additional  bookkeeping  information  to  be  passed 
between  iterations  of  the  transformation,  e.g.,  instead  of  just  g  and  g'  as  the 
old  and  new  function  names,  we  would  have  g°,  g1,  g 2,  etc.,  and  likewise  uflag 
becomes  uflag1 ,  uflag2 ,  etc.  (Interestingly,  no  changes  are  needed  to  translations 
of  running  p,  essentially  since  functions  that  have  not  changed  are  redundantly 
included  in  the  patch  and  distinguished  by  the  transformation.)  Second,  we  must 
change  {|update|}p  to  be  the  identity,  i.e.,  to  leave  the  new  version’s  update  key¬ 
word  in  place,  so  that  it  can  be  used  to  update  to  the  next  version  to  be  merged. 

With  a  more  general  merging  transformation  we  can  prove  properties  about 
multiple  updates.  For  backward-compatible  CO-specs  there  is  no  additional  work 
since  they  are  the  same  across  all  versions.  For  post-update  specifications,  we 
could  generalize  the  transformation  in  Figure  6(a)  so  that  the  assumption  in 
the  loop  is  assume  (running  po  V  •  •  •  V  running  pn-i)  and  the  assumption  after 
the  loop  is  assume  (running  pn),  where  the  post-update  CO-spec  spans  versions 
Po  through  pn.  We  can  make  a  similar  generalization  of  the  transformation  in 
Figure  6(c)  (composing  multiple  conformance  functions  together). 

C  Equivalence  Proof 

This  appendix  presents  a  formal  proof  of  Theorem  1  from  Section  3,  which 
states  that  a  configuration  (p,  a,  e)  updated  by  patch  7r  is  correct  if  and  only 
if  the  merged  configuration  (p,  a,e)  t>  7r  is  correct.  Note  that  the  definition  of 
correctness  given  in  the  paper  specifies  only  a  single  patch  7 r  to  be  applied.  For 
our  proof,  we  generalize  to  correctness  over  sequences  of  patches  7 r. 

C.l  Overview 

The  proof  is  structured  in  three  parts:  First,  we  prove  a  soundness  lemma  show¬ 
ing  that  the  merged  program  simulates  every  step  of  execution  in  the  old  and 
new  programs,  as  well  as  the  updating  step  from  old  to  new.  Second,  we  prove  a 
completeness  lemma  showing  that  every  execution  in  the  merged  program  corre¬ 
sponds  to  an  execution  in  the  original  program,  the  new  program,  or  the  updated 
program.  Finally,  we  use  these  results  to  prove  the  main  equivalence  result. 
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Mp’”  =  * 

HP,7r  =  a 

lgY’n  =  /  9ptr  if  P ^  =  Xx'e 
1  g  otherwise 

PF’"  =  i 

[(«i,ua)r,r  =  (i»ir,Nw) 
lOF’"  =  0 

[«1  op  V2}P’n  4  [«!]»>■*  op  [  V2f^ 

i«1(«a)]'’-,r  4  [wiF^a^F’") 

|7JP,7T  A  ? 

Ivi  :=  V2F'"  =  faF’*  :=  NF’" 

JIvF’77  4  ![vf  ^ 

[ref  vF’71  =  ref  [vf’,r 
[if  v  ci  e2F,7r  =  if  Hp,7r  [ei F’"  NF’" 

[let  a;  =  ei  in  e2F,7r  —  let  x  =  [e2F,7r  'n  [^F’* 

[while  ei  do  e2}p,n  —  while  [ei]p,,r  do  [e2F,7r 
[update]p’^P7r,e7r->  4  let  a  =  isupdQ  in 

if  2  0  (u flag  :=  ?;  let  2  =  isupdQ  in  if  2  ({|e„-|}p  ;  1)  0) 
[assume  «]p,7r  =  assume  [u]p,7r 
[assert  ti]p,lr  =  assert  [v]p,7r 

{let  2  =  isupdQ  in  2  =  0  if p"  —  p 
let  2  =  isupdQ  in  2  ^  0  if  p"  =  pn 
let  2  =  0  in  2  otherwise 

[error]p,7r  4  error 


lp,(g,Xy-e)r^  =  MP’\ 

(g,Xy.lem, 

{gPtr,  Ay. let  2  =  isupdQ  in  if  2  g'(y)  g(y)) 
[•]p,7r  =  (•,  (isupd,  Ay. let  2  =  ! uflag  in  2  >  0)) 

Fig.  7.  Merging  old  version  code. 


Before  we  present  these  lemmas,  we  need  a  little  notation.  We  define  three 
merging  transformations — for  old-version,  new-version,  and  combined-version 
code.  The  first  two  complete  the  presentation  of  merging  given  in  Figure  3.  Fig¬ 
ure  7  fully  defines  the  transformation  [•p,7r  which  applies  to  old-version  code, 
and  Figure  8  fully  defines  {j  •  |}p,  which  is  used  with  new-version  code.  The 
highlights  of  these  transformations  were  explained  in  Section  3.3.  For  technical 
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M”  =  * 

{H}P  =  a 

{|5|1.P  a  U  if  p(a)  =  A x.e 
1  g  otherwise 

Mp  =  < 

fl(«i,^)r  =  (frrj»2n 

flor  =  o 

{|«1  op  V2V  =  {|wi|}P  op  {|v2|}P 

(K’lM|}P  4  (M}P({M}P) 

{|?|}P  A  ? 

flui  :=  ^2|}p  =  {|vi|}p  :=  -G«2|}p 
«P  =  !MP 

{|  ref  «|}p  ±  ref  {|  y|}p 

differ  62  |}p  —  if  {|v|}p  {|ei|}p  {|  62  |}p 

{| let  x  =  ei  in  e2|}p  =  let  x  =  (|ei|}p  in  {|e2|}p 

{| while  ei  do  e2|}p  =  while  {|ei|}p  do  {|e2|}p 

{]updatej}p  =  let  z  =  0  in  z 

{|assume  v|}p  =  assume  {|u|}p 

{|assert  u|}p  =  assert  {|t>|}p 

.  „„p  a  f  let  z  — —  1  in  2  \ip  =  p" 

{j  running  p  |}p  =  < 

I  let  2:  =  0  in  z  otherwise 

{|errorJ}p  =  error 


(I P,  {g.Xy.eW  ±  {\p\Y,  {g\\y.{\e\Y) 
(I  •  !}P  =  • 

Fig.  8.  Merging  new  version  code. 


reasons,  we  modify  the  transformations  slightly  so  that  non-values  (e.g.,  update) 
map  to  non- values  (e.g.,  let  z  =  0  in  z  instead  of  0).  The  third  transformation 
d  •  Dp’p"  combines  [-]p,7r  and  {|  •  |}p  and  returns  a  set  of  expressions  as  a  result.  For 
example,  it  translates  function  pointers  g  to  {g',gptr}-  The  (|  •  Dv  transformation 
is  needed  because  after  the  simulated  update  takes  place,  function  pointers  / 
may  either  bind  to  old/new  versions  fvtr  or  to  new  versions  f . 
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<\x\r^  4 

d4p'p*  = 

M™”  = 

(I'D7''""  = 
a(w1,«2)D*’’*”r  = 
flOD*’-1’*  = 

d«l  op  v2\)p’p”  = 

flw1(w2)D*’-»>-  4 

(|?|)P,P7r  A 
(\Vl  :=  V2\)P^  4 
(|!v|)p’p-  4 
dref  v\)p’p”  = 
flif  v  ei  e2|)p’p-  4 
diet  x  =4  e\  in  e2|)p,p,r  = 
dwhile  ei  do  e2|)p,p,r  — 
dupdate|)p,p,r  = 
dassume  v\)p’p'T  = 
dassert  v\)p’P7T  = 


[running  p 


"h p.ptt  A 


rip.PTr  a 


{*} 

{«} 

W,gPtr}  ifp(g)=\x.e 
{<?}  otherwise 

(0 

{(v[,v'2)  \  v[  £  (\Vl\)p'p”  Av^  £  M™”} 

{()} 

{v[  opv'2  |  v[  £  dvi|)p’PT  A  t>2  €  dv2|)p’p-} 

WM)  |  v[  e  d^iirp'  e  d^r^} 

{?} 

{«i  :=  va  |  «i  6  d'yi|)p,p,r  A  v2  6  d^D”’1”} 

{It/  |  v'  £  dv|)p’p,r} 

{ref  v'  |  v'  £  dn|)p’p,r} 

{if  t/  ei  ei  |  u  G  d«l)P’P,r  A  e{  €  dei|)p’p-  A  ei  €  de2|)p’p-} 
{let  x  =  e{  in  ei  |  e{  €  (\ei\)p,P7r  A  ei  €  de2|)P,P,r} 

{while  ei  do  ei  |  e{  €  dei|)p’p’r  A  ei  e  de2|)p’p’r} 

{let  z  =  0  in  z} 

{assume  v'  \  v'  £  d'yl)P’P,r} 

{assert  v'  \  v'  £  d"e|)p’p,r} 

{let  z  =  0  in  z,  let  z  =  isupd{ )  in  2  =  0}  if  p"  =  p 

{let  z  =  1  in  z,  isupdQ}  if  p"  =  pn 

{let  z  =  0  in  z}  otherwise 

{error} 


Fig.  9.  Merging  combined  version  code. 


Next,  using  these  transformations  on  expressions,  we  define  a  transformation 
on  configurations: 


(p;  cr;  e)  >  t r  =  (p,  a[uflag  i -it],e) 

(p;  a;  e)  [>]  7 r  4  (p,  a[uflag  H>  j],e) 
where  p  =  {| p„  |}p” ,  [ p]p>7r 
e  =  [e]p,7r 

(7  =  {M  [n]p’7r  |  cr(Z)  =  t>} 
cr  =  {cr'  |  dom{(j')  =  dom(a)  A  VZ  €  dom(a).  cr'(l)  £  (|cr(7)|)p’p,r} 


7T  —  (Pm  ^7r) 


=  fleiP.P- 


i  <  0 
j  >  0 


The  (•  >  •)  and  (•  [>]  •)  transformations  simulate  the  behavior  of  the  program 
before  and  after  the  update  occurs  respectively.  Note  that  both  transformations 
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describe  sets  of  configurations:  (•  >  •)  contains  all  configurations  of  the  specified 
form  where  uflag  is  bound  in  the  heap  to  an  integer  *  <  0  while  (•  [>]  •)  is  a 
set  due  to  the  use  of  (|  •  |)p,p,r.  These  sets  are  needed  to  set  up  the  simulations 
between  executions  in  the  old,  new,  and  transformed  programs.  To  streamline  the 
presentation  we  will  occasionally  abuse  notation  slightly,  lifting  various  notions 
from  elements  to  sets  in  the  obvious  way.  For  example,  we  write  (p;  cr;  e)  t>  tt  ^ 
(p;er';e/)  [t>]  ir  to  indicate  that  every  configuration  in  (p;  ct;  e)  >  ir  steps  to  a 
configuration  in  (p;cr,;e/)  [>]  n. 

The  first  lemma  states  that  any  execution  in  an  untransformed  program  is 
matched  by  an  execution  in  the  transformed  program. 

Lemma  1  (Soundness)  For  all  p,p',  cr,  cr',  e,  e',  v,  tt  with  tt  =  (p^,ew)  we  have 
(p;  ct;  e)  (p';  cr';  e!)  implies 

1.  if  v  =  e  then  p'  =  p  and  (p;  cr;  e)  >  7 r  *  (p;  ct';  e!)  >  7r 

2.  if  F  =  tt  then  p' =  Pk  and(p;a;e)  >  n  (p;cr';e')  [>]  tt. 

The  second  lemma  states  that  for  any  execution  trace  of  the  transformed 
program,  there  is  a  corresponding  trace  of  the  untransformed  program.  However, 
the  transformed  program  may  need  to  execute  a  little  more  to  match  up  with 
an  untransformed  state. 

Lemma  2  (Completeness)  For  all  p,p'  ,a,a'  ,e,e' ,  tt  such  that  n  =  (pw,ev),  if 
(p;cr;e)  >  7r  ( p';cr';e ')  then  there  exist  ct"  and  e"  such  that 

—  (p';  cr';  e!)  (p;  c r";e")  >  7r  and  (p;  a;  e)  "^>*  (p;cr",e")  ;  or 

-  (p';a';e')  ^>*  (p;cr";e")  [>]  7r  and  (p;cr;e)^*  (pw;cr",e")  ;  or 

Using  these  lemmas,  we  prove  the  main  result: 

Proof  (of  Theorem  1).  Recall  the  statement  of  the  theorem: 

For  all  p,  ct,  e,7r  with  7r  =  (p^e^)  and  dom(p^)  3  dom(p)  we  have 
\=  (p;cr;e),7r  if  and  only  if  [=  (p,  cr,  e)  >  tt. 

We  prove  each  direction  separately. 

(*^=)  Let  (p;  ct;  e)  >  7r  ^  *  (p';  ct';  e!)  be  an  execution  of  the  transformed  program. 
By  Lemma  2  there  exists  a  cr"  and  e"  such  that  either: 

—  (p';  ct';  e!)  ( p ;  ct";  e")  >  7r  and  (p;  cr;e)  (p;  cr";  e").  By  assumption, 

we  have  \=  (p;  ct;  e),  7r  and  hence  e"  is  not  error.  Using  Lemma  8  we  also 
have  that  e!  is  not  error. 

—  (p,;CT,;e/)  (p;cr";e")  [>]  tt  and  (p;cr;e)  (p';  ct";  e").  The  result 

follows  by  a  similar  argument  as  the  previous  case. 

(=>)  Let  (p;  ct;  e)  (p';  cr';  e!)  be  an  execution.  By  Lemma  1  we  have: 

—  v  =  e  implies  p'  =  p  and  (p;  ct;  e)  >  7r  *  (p;  ct';  e!)  >  tt.  By  assumption, 
we  have  \=  (p;cr;  e),7r  and  hence  [e,]p,7r  is  not  error.  Using  Lemma  8  we 
also  have  that  e'  is  not  error. 

—  v  =  tt  implies  p'  =  pw  and  (p;  ct;  e)  >  tt  (p;  ct';  e')  [>]  7r.  The  result 

follows  by  a  similar  argument  as  the  previous  case.  □ 


CS-TR-4997 


C.2  Soundness  Lemmas 

The  main  soundness  lemma  follows  from  the  three  lemmas  proved  in  this  sec¬ 
tion.  The  first  shows  that  the  simulation  between  the  original  and  transformed 
programs  holds  before  to  an  update  when  taking  a  single  step. 

Lemma  3  For  all  p,  a,  o' ,  e,  e',  tt,  if  (p;  a;  e )  (p;  cr';  e ')  then  (p;  cr;  e)  >  ir  + 

( P;o-';e ')  >  7T. 

Proof.  Let  (p^,  efl)  =  tt  and  define  p,  cr,  and  cr'  as  follows: 

p  =  {Iptt  IF*  bF,7r 

cr  =  {Z  i — >-  [v]p,7r  |  a(l)  =  v}[uflag  H »  z] 
a'  =  {l  i— >■  [w]p,7r  |  cr7 (Z)  =  v}[uflag  H >  z'] 

where  z  <  0  and  z'  <  0. 

The  proof  is  by  induction  on  (p;  cr;  e)  (p;cr,;e/).  Most  cases  are  straight¬ 
forward  calculations  using  the  definition  of  the  transformation.  We  show  just  a 
few  of  the  most  interesting  cases. 

Case  (p;  cr;  v\  op  v2)  (p;  cr;  z/)  where  v'  =  [op] (iq,  v2): 

For  this  case,  we  must  assume  that  [op](iq,  v2)  =  v'  implies  [op]([z;i]p’7r,  [u2]p,7r)  = 
[u/]p,7r.  This  rules  out  operators  such  as  <  on  function  pointers  (which  makes 
intuitive  sense,  because  relative  ordering  on  pointers  will  not  be  preseved  by 
the  transformation  in  general).  We  calculate  as  follows, 

(p;  cr;  vi  op  v2)  >  tt  =  (p;  a;  [iq  op  v2]p’w) 

=  (p;ct;  [oiF,7r  op  |u2F,7r) 

^  (p;d;  [op]([uiF’F  Mp,7r)> 

=  (p;  cr;  [z/F,7r)  >  tt  by  assumption 

=  (p;  cr;  i/)  >  7 r 

and  obtain  the  required  result. 

Case:  (p;  cr;  update)  (p;  cr;  0) 

We  calculate  as  follows, 

(p;  cr;  update)  >  7r 

=  (p;ct;  [updateF’77) 

=  (p;  if;  let  2  =  isupdi)  in 

if  3  0  ( uflag  :=?;  let  z  =  isupd()  in  if  2  ({|ew[j-p;  1)  0)) 

(p;u;let  z  =  let  z  =  \uflag  in  2  >  0  in 

if  3  0  ( uflag  :=?;  let  z  =  isupd()  in  if  2  ({|ew|}p;  1)  0)) 

-^■+  (p;ct;  (uflag  :=?;  let  z  =  isupd()  in  if  z  ({|e^|}p;  1)  0)) 

(p’Muflag  z'];0) 

=  (p;v[uflag  ^  i'}\  [0]^) 

=  (pw;  0)  >  tt 


as  a(uflag)  =  i  <  0 
where  i'  <  0 
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and  obtain  the  required  result. 

Case:  (p;  cr;  update)  ( p '■  cr;  (e;  1))  where  7 r  =  (p' ,  e) 

Can’t  happen,  as  V  =  e  by  assumption. 

Case:  (p;  cr;  running  p)  (p;  cr;  1) 

We  calculate  as  follows, 

(p;  cr;  running  p)  >  7T  =  (p;  a;  [running  p]p’7r) 

=  (p;u;  let  z  =  isupd()  in  z  =  0) 

(p;cf;  let  z  =  let  z  =  \uflag  in  z  >  0  in  z  =  0) 

(p;a;  1)  as  o(uflag)  =  i  <  0 

=  (p;o;  [l]p,7r) 

=  (p;  c;  i)  >  rr 
and  obtain  the  required  result. 

The  next  lemma  proves  the  simulation  is  also  preserved  by  updates. 

Lemma  4  For  allp,p' ,  cr,  o' ,  e,  e',  7r  with  ir  =  (pff,  eff)  we  have  (p;  cr;  e)  (p';  cr';  e') 
implies  p'  =  p, T  and  ( p;  cr;  e )  >  7r-^+  (p;o';e')  [>]  7r. 

Proof.  Let  (pT,  eff)  =  7r  and  define  p,  cr,  and  cr'  as  follows. 

P  =  {\Pn\}P,  bF,7r 

rr  =  {Z  i — >-  [v]p,7r  |  cr(Z)  =  u}[«/Za<7  i  ^  i] 

o'  =  {cr'fzt/Za^  i — j]  |  dom(o')  =  dom(o )  A  VZ  G  dom(o).  o'{l)  €  (]cr(Z)|)p’p,r} 
where  z  <  0  and  j  >  0. 

The  proof  is  by  induction  on  (p;  cr;  e)  ^  (p';  cr';  e').  We  show  just  one  case: 

Case:  (p;  cr;  update)  ^  (pw;  cr;  (e^;  1)) 

We  calculate  as  follows, 

(p;  cr;  update)  >  7r 
=  (p;o;  let  z  =  isupdQ  in 

if  z  0  ( uflag  :=?;  let  z  =  isupd()  in  if  z  ({|eT|}p;  1)  0)) 

+  (p;  d;  let  z  =  0  in  as  o (uflag)  =  i  <  0 

if  z  0  ( uflag  :=?;  let  z  =  isupd( )  in  if  z  ({|eT|}p;  1)  0)) 

+  ( p;o[uflag  i-A  j];  let  z  =  isupd()  in  if  z  ({|e7r|}p;  1)  0)  where  j  >  0 

<p;o[uflag^j];({  \e^p\l)) 

G  (p;o[uflag  ^  j];<\ew;l\)p’p^) 

C  (p;  cr;  (e^-;  1))  [t>]  7r 

and  obtain  the  required  result. 

The  third  lemma  proves  that  the  simulation  is  preserved  following  an  update. 

Lemma  5  For  allp ,  cr,  cr',  e,  e! ,  tt  with  7r  =  (pn,  eff)  we  Zzaue  (pT;  cr;  e)  (pff;  cr';  e!) 
implies  ( p;  cr;  e )  [>]  7r^>  +  (p;cr';e')  [>]  7r. 

Proof.  Similar  to  the  previous  soundness  lemmas. 
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C.3  Completeness  Lemmas 

The  main  completeness  lemma  follows  from  repeated  applications  of  the  next 
two  lemmas. 

Lemma  6  For  all  p,p'  ,a,a'  ,e,e'  ,tt  where  7r  =  (pv,ev),  if 

(p;cr;e)  >  tt  -^+  (p';a';e') 
and  there  does  not  exist  cto  and  eo  such  that  either 
(p;cr;e)  ^  (p;CT0;e0)  and  (p;er;e)  >  tt  (p;  cr0;  e0)  >  tt  (p';  o';  e') 
or 

(p-a-,e)'^(p'-,a0;e0)  and  {p;cr;e)  >  tt^+  {p-<j0;e0)  [>]  tt  (p';  ex';  e') 
f/ien  tftere  exists  a"  and  e"  such  that  either 

—  (p7; cr77; e")  =  (p\a';e')  >  n  and  (p;cr;e)  (p;cr";e")  ;  or 

-  (p7;  a";  e")  G  (p;cr7;e7)  [>]  tt  and  (p;  a;  e)  (pff;  cr";  e");  or 

—  (p7;  cr';  e7)  ^  (p7;  cr";  e")  /or  some  v. 

Intuitively,  this  lennna  states  that  if  the  transformed  program  can  take  some 
number  of  steps,  then  either  that  state  corresponds  to  a  reachable  untransfornred 
state,  or  can  take  another  step,  eventually  reaching  a  corresponding  state. 

The  second  lemma  is  similar,  but  considers  post-update  states: 

Lemma  7  For  all  p,p7,  cr,  cr',  e,  e7,  tt  where  tt  =  (p^,ew)  ,  if 

(jP',o r;e)  [>]  tt  (p';er';e') 

and  there  do  not  exist  op  and  eo  such  that 

(Ptt!  cr;  e)  (pff;  cr0;  e0)  and  (p;a;e)  [>}  tt (p;a0;e0)  [\>]  n (p;a';e') 
Then  there  exist  a"  and  e"  such  that  either 

-  { p7;cr7;e ')  G  (p;cr";e")  [>]  7r  and  (pff;cr;e)  (pw;  ct";  e")  ;  or 

-  (p7;cr7;e7)  (p';o-";e"). 

C.4  Auxiliary  Lemmas 

Lemma  8  (Error)  For  all  p,  7r,  e,  we  have  e  7^  error  if  and  only  if: 

-  [e]p’7r  7^  error; 

—  {|e|}p  7^=  error;  and 

—  (|e|)p’7r  ^  error. 

Lemma  9  (Non-Zero)  For  all  p,  7r,  v,  we  have  «  /  0  if  and  only  if: 
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1.  [u]p’7r  ^  0; 

2.  Mp  7^  0/  and 

3.  ^  0. 

Lemma  10  (Substitution)  For  allp,  p' ,  n,  x,  v,  and  e  we  have  the  following: 

-  {e[v/x\Y’«  =  le\^M^/x\; 

“  {I e[v/x}\}p  =  Mp[{H}p/z]>-  and 

-  <\e[v/x]rp-  =  (\e\rp-Mp’p" /x}. 


